-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future-proof indexing on maps: remove IndexMut #23559
Conversation
This commit removes the `IndexMut` impls on `HashMap` and `BTreeMap`, in order to future-proof the API against the eventual inclusion of an `IndexSet` trait. Ideally, we would eventually be able to support: ```rust map[owned_key] = val; map[borrowed_key].mutating_method(arguments); &mut map[borrowed_key]; ``` but to keep the design space as unconstrained as possible, we do not currently want to support `IndexMut`, in case some other strategy will eventually be needed. Code currently using mutating index notation can use `get_mut` instead. [breaking-change] Closes rust-lang#23448
Note that I did not remove from |
{ | ||
fn index_mut(&mut self, key: &Q) -> &mut V { | ||
self.get_mut(key).expect("no entry found for key") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oof, I dunno if we'll be able to accurately reproduce such complex functionality.
@bors r+ |
📌 Commit 5fe0bb7 has been approved by |
⌛ Testing commit 5fe0bb7 with merge 7740b61... |
💔 Test failed - auto-win-32-opt |
@bors: retry On Sat, Mar 21, 2015 at 6:05 AM, bors notifications@github.com wrote:
|
…nkro This commit removes the `IndexMut` impls on `HashMap` and `BTreeMap`, in order to future-proof the API against the eventual inclusion of an `IndexSet` trait. Ideally, we would eventually be able to support: ```rust map[owned_key] = val; map[borrowed_key].mutating_method(arguments); &mut map[borrowed_key]; ``` but to keep the design space as unconstrained as possible, we do not currently want to support `IndexMut`, in case some other strategy will eventually be needed. Code currently using mutating index notation can use `get_mut` instead. [breaking-change] Closes rust-lang#23448 r? @gankro
⚡ Previous build results for auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-64-opt are reusable. Rebuilding only auto-linux-32-nopt-t, auto-linux-32-opt, auto-mac-32-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t... |
💔 Test failed - auto-mac-32-opt |
@bors: retry On Sat, Mar 21, 2015 at 4:10 PM, bors notifications@github.com wrote:
|
⌛ Testing commit 5fe0bb7 with merge c6a0865... |
…nkro This commit removes the `IndexMut` impls on `HashMap` and `BTreeMap`, in order to future-proof the API against the eventual inclusion of an `IndexSet` trait. Ideally, we would eventually be able to support: ```rust map[owned_key] = val; map[borrowed_key].mutating_method(arguments); &mut map[borrowed_key]; ``` but to keep the design space as unconstrained as possible, we do not currently want to support `IndexMut`, in case some other strategy will eventually be needed. Code currently using mutating index notation can use `get_mut` instead. [breaking-change] Closes rust-lang#23448 r? @gankro
💔 Test failed - auto-linux-32-nopt-t |
@bors: retry |
This feature was removed in rust-lang/rust#23559.
This commit removes the
IndexMut
impls onHashMap
andBTreeMap
, inorder to future-proof the API against the eventual inclusion of an
IndexSet
trait.Ideally, we would eventually be able to support:
but to keep the design space as unconstrained as possible, we do not
currently want to support
IndexMut
, in case some other strategy willeventually be needed.
Code currently using mutating index notation can use
get_mut
instead.[breaking-change]
Closes #23448
r? @gankro